There are currently various embedded hardware systems that are commercially available to financial market participants and their clients which provide a combination of both pre trade and post trade risk assessments, real-time market data and trading connectivity to numerous liquidity venues listing financial instruments. The financial instruments may include securities, options, futures, commodities and foreign exchange. These current systems provide financial market trading participants with the fastest available electronic market data and trading connectivity to liquidity venues. The current systems also provide intra-day trading risk assessments for both the financial market trading participant and the electronically connected trading clients of the financial market trading participant.
At present the most common type of embedded hardware used for such risk systems are User Programmable Hardware Chips (UPHCs) such as Field Programmable Gate Arrays (FPGA), Programmable Object Arrays (FPOA) or an Application-Specific Integrated Circuit (ASIC) microchips.
As part of the risk function, current embedded hardware risk systems are required to manage multiple messages in which each message contains a Client Order Identifier (CLOrID) that can be up to 64 Bytes in length (depending upon the message protocol). These message protocols include Financial Information Exchange Protocol (FIX), OUCH and other industry standard formats as operated by both liquidity venues and trading participants.
The use of these standard message protocols with CLOrID message lengths of up to 64 Bytes causes two problems within a UPHC. Firstly, to use this CLOrID value as a unique memory location requires a memory space far larger than that accessible by a UPHC. Essentially, a UPHC does not hold enough memory space for the whole CLOrID to be mapped in its entirety as it would require a memory location size of 264 Bytes for each CLOrID to be written to memory. Secondly, the ClOrID is made up of alpha-numeric characters which do not map to a numerical address memory space as typically found in UPHCs.
To date, these two problems have been resolved by a traditional two stage procedure known as ‘hashing’. In the hashing process, the alpha-numeric CLOrID is transformed into a numerical only value which can then be stored by the UPHC in memory. In addition, the numerical CLOrID is also truncated/shortened so that the resulting value can be sized to fit in the available memory address space within the UPHC.
However, while the traditional hashing procedure does resolve the initial issues of ClOrID message length and Alpha Numeric message incompatibility, it is unfortunately not without weakness as a solution. Specifically, the process of converting the CLOrID to a Numerical value (which is then subsequently truncated), can lead to a problem known as a ‘hash collision’. A hash collision can occur when two original CLOrIDs (that are originally different) are mapped to a common address value due to the process of truncation. Essentially, truncation of the newly formed numeric CLOrID can mean (in times of high message throughput and memory use) that the CLOrID is no longer unique because the value has been truncated to a smaller value that might already be in use. For example, as shown in FIG. 1, two different orders (order A and order B) with two unique original CLOrIDs are transformed into a numeric value which is then truncated which result in the hash collision since the truncated identifiers are not unique even though the original CLOrIDs were unique.
Traditionally, such hash collisions have been managed by incrementing the second memory address until a free memory location is identified as shown in FIG. 3 via a process known as linear searching.
Statistically, as more orders are hashed and stored due to greater trading throughput, the likelihood of a hash collision becomes greater. This is especially prevalent when the system is dealing with thousands of concurrent orders. Additionally, due to the volume of concurrent orders being managed in memory, the likelihood of an adjacent memory location being free in the event of a hash collision is reduced so that the above traditional linear searching does not work very well. This in turn leads to a forth problem affecting overall system latency.
As previously described, when a hash collision occurs, the system must increment the second truncated CLOrID memory address until it can find an empty memory location via a linear search as shown in FIG. 3. However, if the next available memory space is not adjacent to the existing hash collision memory location, the system is required to search through possibly the entire memory space range for an available memory location.
In such circumstances it is not unusual for between 10 to 20 increments of memory space location linear searches to be required before a free location is found. The number of simultaneous linear search cycles taking place can cause a memory access latency penalty when the memory usage approaches more than 50% of capacity. The memory access penalty to each linear search results in a non-deterministic latency performance affecting all messages within the UPHC. Accordingly, given that the UPHC's primary function is to provide risk calculations in the lowest time possible in order to improve trading performance, the effect of any increase in system latency due to memory utilisation issues is harmful.
In system tests in which each memory entry CLOrID was stored in 256 Bytes of memory, the system was utilising 1 Gb of RAM and with the UPHC system employing a traditional hashing & Linear Search methodology, it was observed that after about 2000 orders, hash collisions began to occur and that after about 5000 orders, the linear searching method impacted overall UPHC latency.
In the tests, latency was calculated on the basis that the UPHC would typically take 1 μs (microsecond) to process a ‘Single Order Message’ and that the SDRAM housed within the UPHC card would take 185 ns (nanoseconds) to perform a linear search. Accordingly, the increase in latency for each new order was calculated as follows:1 μs+(No of linear searches×185 ns)
As each order was entered into the system, the latency was measured to determine the amount of time that the order took to be written to memory. Any increase in latency as more orders were entered into the system would be directly attributable to the amount of hash collisions occurring and the amount of subsequent linear searches taking place a result.
The results demonstrated that the current hashing and linear search memory mechanisms in use within current UPHC risk platforms result in a maximum throughput of concurrent order messages of approximately 5000 before the systems become unfit for its intended purpose. For most organisations employing such UPHC devices to perform their risk analysis, an order throughput rate of 5000 concurrent orders is far below the minimum requirement.
Consequently, it is desirable to provide an embedded hardware based risk system with a new design and method for the management of unique alpha-numeric order message identifiers within DDR memory space restrictions and it is to this end that the disclosure is directed.